1. Technical Field
The present invention relates to security analysis and, more particularly, to automatic correction and enhancement of user-implemented security downgraders.
2. Description of the Related Art
Static security analysis typically takes the form of taint analysis, where the analysis is parameterized by a set of security rules, each rule being a triple <Src,San,Snk>, where Src denotes source statements that read untrusted user inputs, San denotes downgrader statements that endorse untrusted data by validating and/or sanitizing it, and Snk denotes sink statements which perform security-sensitive operations. Given a security rule R, any flow from a source in SrcR to a sink in SnkR that doesn't pass through a downgrader from SanR comprises a potential vulnerability. This reduces security analysis to a graph reachability problem.
Traditionally, the goal of security analysis has been to detect potential vulnerabilities in software applications (mostly web applications) and to inform the user of these problems. The user would then apply a fix, typically by introducing a downgrader (such as a sanitizer or validator function) into the flow of the computation. For example, if an analysis tool were to discover that an application is able to read user-provided data (e.g., an HTTP parameter) and then use this data in a security-critical operation (e.g., writing it to a database or to a log file), then one of the flows extending between these two endpoints would be reported to the user. Such a flow is a security risk, as it potentially allows users to corrupt or subvert the security-critical operation.
To remedy the problem, the user would install one or more security checks covering all flows between the endpoints to ensure that data reaching the security-sensitive operation is benign by, e.g., transforming it through sanitization, or to reject the data through validation. This solution is limited, however, in that the tool assumes, rather than verifies, that the security checks inserted by the user are correct. Implementing and using downgraders correctly is highly nontrivial, and users are prone to making errors. In particular, there are many end-cases to account for, the correctness of a check often depends on the deployment configuration of the software system (e.g., the type of backend database), and the context where the vulnerability occurs also partially determines what needs to be check. A user may err either in tool configuration, e.g., by defining incorrect downgraders, or in the remediation of reported vulnerabilities.